Built on top of `--auto-pch` (in-memory) introduced in
intel#20226.

The most significant technical decision was how to implement the
filesystem cache. I've looked into the following options:

* `sycl/source/detail/persistent_device_code_cache.hpp`
  Also, see `sycl/doc/design/KernelProgramCache.md` Seems to be tailored
  for the very specific usage scenarios, would be very resource
  consuming to split into a generic data structure that would then be
  used for two different use cases.

  This cache is disabled by default and I'm not sure how well-tested it
  is. Also, using plain ".lock" files for "advisory locking" instead of
  the native filesystem mechanisms (e.g., locking APIs in
  `fcntl`/`flock`/`CreateFile`/`LockFileEx`) made me question if it's
  worth generalizing and how much work would be necessary there.

* `llvm/include/llvm/Support/Caching.hpp`
  Originally implemented as part of ThinLTO implementation, moved into
  `LLVMSupport` later with the following commit message:

    > We would like to move ThinLTO’s battle-tested file caching
    > mechanism to the LLVM Support library so that we can use it
    > elsewhere in LLVM.

  API is rather unexpected, so my research hasn't stopped here.

* `lldb/include/lldb/Core/DataFileCache.h`
  Uses `LLVMSupport`'s caching from the previous bullet under the hood,
  but provides an easier to grasp API. If we were developing upstream I
  think uplifting that abstraction into `LLVMSupport` library and then
  using in both `lldb` and `libsycl` would probably be the choice I'd
  vote for. However, doing that downstream was too much efforts so I
  ultimately decided not to go with this approach.

  That cache also has a `std::mutex` on the "hot"
  `DataFileCache::GetCachedData` path, I presume to avoid creating the
  same entry from multiple threads.

In the end, I've chosen to use `LLVMSupport`'s quirky (or maybe I just
hasn't grown enough to appreciate it) caching API directly and that's
what is done in this PR. Unlike 'lldb''s cache I decided to trade
possible duplicate work of building the preamble on a cache miss from
concurrent threads in favor of no inter-thread synchronization on the
cache hit path (not profiled/measured though).

Built on top of `--auto-pch` (in-memory) introduced in
intel#20226.

The most significant technical decision was how to implement the
filesystem cache. I've looked into the following options:

* `sycl/source/detail/persistent_device_code_cache.hpp`
  Also, see `sycl/doc/design/KernelProgramCache.md` Seems to be tailored
  for the very specific usage scenarios, would be very resource
  consuming to split into a generic data structure that would then be
  used for two different use cases.

  This cache is disabled by default and I'm not sure how well-tested it
  is. Also, using plain ".lock" files for "advisory locking" instead of
  the native filesystem mechanisms (e.g., locking APIs in
  `fcntl`/`flock`/`CreateFile`/`LockFileEx`) made me question if it's
  worth generalizing and how much work would be necessary there.

* `llvm/include/llvm/Support/Caching.hpp`
  Originally implemented as part of ThinLTO implementation, moved into
  `LLVMSupport` later with the following commit message:

    > We would like to move ThinLTO’s battle-tested file caching
    > mechanism to the LLVM Support library so that we can use it
    > elsewhere in LLVM.

  API is rather unexpected, so my research hasn't stopped here.

* `lldb/include/lldb/Core/DataFileCache.h`
  Uses `LLVMSupport`'s caching from the previous bullet under the hood,
  but provides an easier to grasp API. If we were developing upstream I
  think uplifting that abstraction into `LLVMSupport` library and then
  using in both `lldb` and `libsycl` would probably be the choice I'd
  vote for. However, doing that downstream was too much efforts so I
  ultimately decided not to go with this approach.

  That cache also has a `std::mutex` on the "hot"
  `DataFileCache::GetCachedData` path, I presume to avoid creating the
  same entry from multiple threads.

In the end, I've chosen to use `LLVMSupport`'s quirky (or maybe I just
hasn't grown enough to appreciate it) caching API directly and that's
what is done in this PR. Unlike `lldb`'s cache, I decided to trade
possible duplicate work of building the preamble on a cache miss from
concurrent threads in favor of no inter-thread synchronization (not
profiled/measured though) on the cache hit path and implementation simplicity.